ci: add a Tag release workflow that bumps and pushes the release tag - #87

Thanks, dispatching the release instead of tagging by hand is a good change. Two things to fix before we use it for 1.4.0, which has to reach CocoaPods trunk before it goes read-only on Dec 2:

1. The tag needs to be bare (1.4.0), not v1.4.0. The podspec's source is :tag => "#{spec.version}", so pod trunk push and every pod install for 1.4.0 look for a tag named 1.4.0. With only v1.4.0 on GitHub, the 1.4.0 pod can't be fetched. That nearly happened with 1.3.0: its release stayed a draft, so no 1.3.0 tag was created. CocoaPods only worked because a 1.3.0 branch was still around, and SPM's from: "1.3.0" didn't resolve at all until the tag was published on Nov 9. #85 already moved CI to bare tags for this reason. Pushing ${VERSION#v} instead of ${VERSION} (and passing that to CI) would fix it.

2. Check the computed version against the podspec. tag.yml works out the version from existing tags plus the bump input, while the podspec's spec.version and MARKETING_VERSION are bumped separately in the release prep PR. If they disagree, for example minor is picked when the prep PR said 1.3.1, the tag won't match what the podspec publishes. A step that fails unless the computed version equals spec.version in OptableSDK.podspec would catch that. Alternatively, read the version from the podspec instead of computing it.

Minor: once this lands, docs/releasing.md should say to run the "Tag release" workflow rather than creating the tag via a GitHub release.